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Abstract — Always Best Packet Switching (ABPS) is a novel 
approach for wireless communications that enables mobile nodes, 
equipped with multiple network interface cards (NICs), to 
dynamically determine the most appropriate NIC to use. Using 
ABPS, a mobile node can seamlessly switch to a different NIC in 
order to get better performance, without causing communication 
interruptions at the application level. To make this possible, 
NICs are kept always active and a software monitor constantly 
probes the channels for available access points. While this ensures 
maximum connection availability, considerable energy may be 
wasted when no access points are available for a given NIC. 
In this paper we address this issue by investigating the use of 
an "oracle" able to provide information on network availability. 
This allows to dynamically switch on/off NICs based on reported 
availability, thus reducing the power consumption. We present 
a Markov model which allows us to estimate the impact of the 
oracle on the ABPS mechanism: results show that significant 
reduction in energy consumption can be achieved with minimal 
impact on connection availability. We conclude by describing a 
prototype implementation of the oracle based on Web services 
and geolocalization. 

I. Introduction 

The current generation of mobile devices (smartphones, 
tablets, laptops) is frequently equipped with several Network 
Interface Cards (NICs) (e.g. 3G, WiFi). The user must manu- 
ally select which interface to use at any given time, according 
to the availability of Access Point (AP) within communication 
distance. In order to make better use of multiple interfaces, 
we recently proposed the Always Best Packet Switching 
(ABPS) mechanism fil-B). ABPS keeps all interfaces active 
at the same time, and uses the best one for data transmission 
according to predefined criteria (e.g., availability or connection 
quality). Furthermore, ABPS can automatically switch to a 
different NIC when the current connection terminates. The 
interesting feature of ABPS is that all this is carried out trans- 
parently to the applications and without any user intervention. 
The idea is that a software component running in the Mobile 
Node (MN) dynamically selects a "preferred" NIC to use 
based on the available access points. If the performance of 
that preferred NIC degrades or the connection fails, the MN 
switches to a different NIC. Specifically, for each datagram, 
the MN selects the best NIC to use. 

This work has been partially funded by the Italian Ministry of Educa- 
tion, University and Research (MIUR) through project STEM-Net (Prot. 
2009S7RLXY_003 - Year 2009). A revised version of this paper appears 
in the proceedings of Wireless Days 2012, Novembre 21-23 2012, Dublin, 
Ireland. 



A prototype implementation of ABPS is available (3), 
and supports interactive multimedia services based on 
SIP/RTP/RTCP. In (T| we have shown that our approach 
provides better performance in terms of availability, reliability 
and throughput, with respect to conventional wireless commu- 
nication services. In (2) we studied the power consumption 
of ABPS: our analysis revealed that, under some realistic 
conditions, ABPS requires less energy than traditional sin- 
gle NIC systems, and other classic Session Initiation Protocol 
(SlP)-based multi-NIC communication approaches. However, 
a particular aspect of ABPS is that a software module at 
the MN continuously monitors all the NICs and probes the 
communication channels looking for access points to connect 
to. When there are no access points for a specific NIC in 
the current area, keeping that interface active has no practical 
benefit and negatively affects the MN battery duration (4j. 

In this paper, we propose an extension to ABPS based on an 
additional software component-called "oracle"-that is respon- 
sible for predicting the availability (or lack of) of access points 
for the available interfaces. Using this information, the MN 
can decide to switch off a NIC for which no access points are 
currently available. We describe a prototype implementation 
of the oracle based on a software daemon which periodically 
queries the WiGLE Web service (5) to locate WiFi networks 
within the current MN location. 

To evaluate the impact of the oracle on connection avail- 
ability, power consumption and throughput, we define a per- 
formance model based on Continuous Time Markov Chains 
(CTMCs) with rewards. The model allows us to efficiently 
analyze the system in different scenarios; such analysis would 
be impractical using conventional measurement-based tech- 
niques. Results show that ABPS enhanced with the oracle can 
significantly reduce the power consumption of the MN, with 
just a marginal reduction of availability and throughput with 
respect to the classic ABPS. We believe that the performance 
model is useful by itself, as it can be easily extended to 
describe multiple alternative implementations of the oracle, 
allowing "what-if" analyses to be carried out efficiently. 

This paper is organized as follows. Section |H| briefly intro- 
duces the ABPS mechanism and describes the extension based 
on the oracle. In Section [III] we describe an initial prototype 
implementation of the oracle based on the WiGLE service. 



Section IV describes the Markov model exploited to analyze 
the approach. Such model is evaluated in Section [V] Finally, 



concluding remarks are given in Section VI 



Algorithm 1 ABPS Oracle 



II. The System 

A. The Basic ABPS Mechanism 

The idea behind the basic ABPS mechanism is simple: 
during transmission and reception, the MN can use all the 
available NICs simultaneously, differentiating the choice of the 
actual NIC on a datagram-by-datagram basis. This is carried 
out transparently to both the application running in the MN and 
its peer at the Correspondent Node (CN); thus, applications 
can continue to employ classic end-to-end application-layer 
protocols such as TCP regardless of ABPS. 

In order to let the data flow through different NICs, and 
deliver the related contents as a single flow to the applica- 
tion, additional software components are needed. Specifically, 
ABPS requires the ABPS Client Proxy and the ABPS Server 
Proxy (see [3] for details). The Client Proxy runs on the MN 
and maintains the seamless multi-path communication channel 
between the MN and the Server Proxy running on the CN. 
The Server Proxy operates as a relay between the MN and 
the CN, i.e. it collects all the datagrams coming from the MN 
via different NICs, and sends them to the application running 
on the CN (application which is unaware of the presence of 
the ABPS Server Proxy). 

B. An Oracle to Predict Network Availability 

The ABPS uses multiple NICs at the same time, and 
assumes that all of them are always active (although possibly 
not always connected to an AP). This ensures maximum 
connection availability (T), and in some cases the use of ABPS 
can even reduce the power consumption with respect to a 
classic SIP based approach [2|. However, it remains true that 
the monitor at the ABPS client proxy continuously probes 
the communication channels looking for new access points 
to connect to. When there are no access points available in 
the current area, this procedure is useless and wastes energy, 
which is a particularly serious issue for battery-powered 
mobile devices. To avoid such undesired situation, we need 
some component (the "oracle") providing information on the 
available access points for a given NIC, without explicitly 
probing the communication channel. If the oracle reports 
that, for some NIC, no access point will be available for a 
sufficiently long period of time, than that NIC can be safely 
switched off. On the other hand, if the oracle detects that 
the MN is entering an area where access points are available, 
the NIC can be reactivated. 

C. The Algorithm 

Before describing how the oracle may be implemented, 
let us focus in detail on how the oracle can be used by 
considering a practical scenario. We start by observing that 
most current smartphones are typically equipped with both a 
WiFi and a 3G NIC (e.g. UMTS). In general, 2G/3G network 
coverage is quite ubiquitous, while WiFi access points tend 
to be concentrated within densely populated areas (e.g., city 
centers). On the other hand, WiFi provides better bandwidth, 



{no available WiFi network} 



1: upon EV_NO_WIFI 

2: activewiFi false 
3: activeuMTS *~ true 

4: upon EV_SHORT_WIFI {WiFi available for a short period} 

5: activewiFi true 
6: activeuMTS true 

7: upon EV_LONG_WIFI {WiFi available for a long period} 

8: activewiFi true 
9: activeuMTS false 



lower latency and lower energy consumption [2|, therefore 
UMTS networks should always be used as a fallback when no 
usable WiFi connection is available. 

However, if the MN is entering an area where the WiFi 
connection is likely to be available for a short time only 
(e.g., because the MN is approaching an isolated access point), 
switching off the UMTS NIC would not be a good idea since 
that connection will be needed again in a short time. On the 
other hand, if the MN is entering an area where WiFi coverage 
is guaranteed for a sufficiently long time, then it is reasonable 
to switch UMTS off in order to save energy. 

We assume that the oracle has a list of available WiFi access 
points in the current area; also, the oracle knows the current 
position of the MN, and can also infer the future destination 



of the node (see Section III for a possible implementation). 
Algorithm [T] describes the high level behavior of the oracle. 
Based on the list of available WiFi networks, the oracle 
generates one of these events: 

• EV_NO_WIFI: this event is generated with no WiFi 
access point is available; therefore, the WiFi NIC can be 
turned off so that connectivity is provided by the 2G/3G 
network only (lines [TJj3]l. 

. EV_SHORT_WIFI: this event is generated with a WiFi 
connection is going to be available for a short period of 
time; in this case both the UMTS and WiFi NICs are 
activated (lines [4]-[6]i. 

• EV_LONG_WIFI: this event is generated when a WiFi 
connection is going to be available for a longer period of 
time; in this case the MN can safely switch off UMTS 
(lines 0|9j. 

The events (and associated new system configuration) gen- 
erated by the oracle is exploited by the ABPS Client Proxy 
as shown in Algorithm [2] When a given NIC is active, based 
on the oracle prediction, and if an access point is detected 
for that NIC, then the Client Proxy starts a setup procedure 
to activate a connection and exploit it. Upon successful con- 
nection setup, the Client Proxy includes that interface in a 
list of NICs available to transmit data. When a connection 
drops, the associated NIC is removed from the list of active 
interfaces. 

Based on this choice on the NIC to use, the communication 
between the MN and its CN is as follows. The Client Proxy 
intercepts and manages data coming from/to the application 
(lines [T0] - [2"2"| i. When there is data to transmit, the Client sends 
those data to the Server Proxy via the preferred NIC in use. 



Algorithm 2 ABPS Client Proxy 

1: {NICs' management} 

2: upon available connection for NIC A activeNic 
3: SETUPCiV/C) 

4: upon successful setup for NIC A activeNic 
5: availableNICs.ADD(NIC) 

6: inllseNIC SELECTPREFERRED(ai>ai£a&ZeiV/Cs) 

7: upon disconnection for NIC 

8: availableNICs.REMOVE(NIC) 

9: inllseNIC SELECTPREFERREDCamiZa&ZeATCs) 
10: {Communication} 
11: upon new data to transmit 
12: SEND(data, inllseNIC) 
13: SETTlMEOUT(daia) 
14: upon data received from ABPS server proxy 
15: PUSHORDEREDBUFFER(data,6u f ferToApp) 

16: SENDORDEREDDATA(feu/ ferToApp) 
17: upon ACK for data received 
18: REMOVETlMEOUT(dafa) 
19: upon timeout ACK for data 

20: NIC <- auai/aWeiV/Cs. selectAlternativeNIC() 
21: SEND(data, NIC) 
22: SETTlMEOUT(ctoa) 



As multiple networks can be used during the communication, 
it is possible that the transmitted datagrams are received out 
of order. To this end, a sequence numbering scheme is used 
that enables the receiver Server Proxy to order the received 
datagrams and discard possible duplicates. Finally, the Client 
Proxy exploits ACKs to identify if some datagram is to be 
re-transmitted. When a timeout for the reception of an ACK 
occurs, the Client Proxy tries to retransmit that datagram 
through an alternative NIC among those active at that time. 

The ABPS Server Proxy runs on a remote host, separate 
from that of the Client Proxy. The Server Proxy operates 
basically as a relay between the MN and its CN. In practice, it 
is convenient to place the ABPS Server Proxy on a fixed node 
located outside any firewall and NAT system. Then, the ABPS 
Client and Server Proxies collaborate and adopt policies for 
load balancing and recovery, in order to maximize throughput 
and minimize loss rate and economic costs. In particular, 
the ABPS Server Proxy collects all the datagrams coming from 
the MN, via different NICs and sends them to the CN (which 
is unaware of the presence of the ABPS Server Proxy). 

III. Prototype Implementation 

A. WiFi Networks Detection with WiGLE 

We have developed a prototype software module that is in 
charge of periodically querying the WiGLE Web service to lo- 
cate WiFi networks within the area of the mobile user. Wireless 
Geographic Logging Engine (WiGLE) is a submission-based 
Web catalog of wireless networks (51. Such service provides 
location and information of wireless networks world-wide; 
through a java application or a Web browser it is possible 
to map, query and update the database. It allows to obtain 
statistics on the performance of networks, and for instance, 
it is possible to ask only for free (or commercial) networks. 
We have developed a Python script in charge of retrieving 




Fig. 1. WiFi networks in Via Zamboni, Bologna (Italy) 



from WiGLE a list of WiFi access points available in the area 
of the MN, based on its geographical position, together with 
some related information. 

To obtain the actual position of the MN, a positioning 
system must be utilized, i.e. GPS. It has been shown that the 
power consumption related to the use of a GPS is noticeably 
lower than that due to the use of a NIC (6), but in any case the 
evaluation described in Section [V] explicitly takes into account 
the additional energy consumption of the GPS module and the 
associating processing cycles. It is worth noticing that many 
apps running on users' smartphones require the use of GPS to 
locate points of interests (7). Hence, it would be reasonable to 
assume that GPS is likely to be active anyway even without 
the execution of the oracle. In this case, the geolocalizaion 
does not introduce additional power consumption. 

B. Use Cases 

We report a couple of examples in order to show the benefits 
of having an oracle that provides the list of WiFi networks, 
and also some main related issues. 

Let consider a mobile user that covers the path depicted 
in Fig. [T] The path is Via Zamboni in Bologna (Italy), the 
main street in the city center where several departments of the 
University of Bologna are located. In this area there are many 
active WiFi access points. In particular, there are two main 
networks available for students, i.e. the AlmaWiFi network, 
which is the main WiFi network for all students, faculty 
members and employees of the University of Bologna, and the 
Iperbole civic network, available to all citizens. For each point 
in the path, the oracle provides a list of available access points. 
For the sake of a clearer presentation, we report only the essid 
of the access points with the best signal in six main points of 
the path, i.e. those corresponding to a square. The red line in 
the Figure corresponds to the area in the path where there is 
a network coverage provided by the AlmaWiFi Network; the 
green line corresponds to the part of the path that is covered by 
some access points of the Iperbole network. Other networks 
are available in the network coverage of a single access point. 

This example allows us to make some important consid- 
erations. Knowing that a main part of the area is covered 
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Fig. 2. WiFi networks in Via Muni, Bologna (Italy) 



by a single WiFi network (Alma WiFi), the network manager 
of the MN might decide to switch off its UMTS interface. 
Obviously, during the path the mobile terminal will perform 
horizontal handover through different access points of the 
same network, but this is accomplished at the datalink layer, 
transparently to the transport and application layers. Then, 
once the user becomes in proximity of the end of the AlmaW- 
iFi network coverage, the UMTS interface should be activated, 
so as to allow the MN to exploit that interface during the 
handover from a WiFi network to another one, or if no WiFi 
networks are available or open to the user. 

Fig. [2] shows a different path, starting from Giardini 
Margherita, the main park in Bologna, and then straight to 
via Murri, a street originating from the entrance of the park. 
In this case, the oracle reports that there are private networks 
only (we do not show them in the picture); moreover, the 
access points are located at the beginning and the end of the 
path. Apparently, no WiFi networks are available in the middle 
of the path. In this context, the best strategy is to keep the 
UMTS NIC always active; the WiFi interface can be switched 
on when the MN is in proximity of the beginning and the end 
of the path, so that it can probe the available networks and 
see if these networks are open and available. 

IV. Modeling ABPS and the Oracle 

In this section we describe a performance model for ABPS 
with oracle; the model is based on Markov chains with 
rewards, and extends previous works on modeling the 
plain ABPS mechanism (T], (2j. Our model can be solved very 
quickly, and can be used to evaluate the proposed approach un- 
der different parameter settings. We use the model to estimate 
the impact of the oracle on the availability, power consumption 
and throughput of ABPS. The insights provided by the model 
are being used to drive current and future development of the 
oracle-enhanced ABPS prototype. 

Markov chains: We start by giving a very brief in- 
troduction to Markov chains (see (8) for full details). A 



(a) UMTS model 



[Wl] 




(b) WiFi model 

[Wl] Xujjw [UO] \ uw<w 






- * 

-' 




* 

-' 







WO] X uw ,u 




[Ul] \ w , uw 
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Fig. 3. Markov models of ABPS with oracle 



stochastic process {X(t),t > 0}, defined over the discrete 
state space {1, ...,N}, is a CTMC if the probability that 
the system is in state X(t n+ i) at time t n+ i only depends 
on the previous state X{t n ) at time t n , for any t n < t n +\. 
A CTMC can therefore be fully defined in term of an 
infinitesimal generator matrix Q = [Qi.j], where Qij is 
the transition rate from state i to state j ^ i. Given the 
infinitesimal generator matrix and the initial state occupancy 
probability, we can compute the state occupancy probability 
vector n(t) = (tti (t) , TT2 (t) , . . . , 7rjv(i)) at time i, 7r^ (t) being 
the probability that the system is in state i at time t > 0. Under 
certain conditions |8), there exists a stationary state occupancy 
probability 7r = lim f ^ +co Tt(t), which is independent from 
the initial configuration of the Markov chain. Of particular 
interest for our analysis are Markov reward models. We 
associate to each state i € {1, . . . , N} a nonnegative reward 
Ti. Rewards have the following meaning: for each period of 
duration dt spent in state i, the total accumulated reward 
increases by ridt. 

Model Description: The model is composed of three 
interacting CTMCs as shown in Fig. [3] The chain in Fig. |3(a)| 
represents the UMTS NIC, the one in Fig. 3(b) represents the 
WiFi NIC, and finally the chain in Fig. 3(c) represents the 
oracle. 



The UMTS and WiFi models are identical (except for 
the parameter values), so we focus on the UMTS chain 



shown in 3(a) The chain is defined over the state space 
{O;/, djj, sjj, cjj, fu}', note that, for readability, we give sym- 
bolic names to states instead of numeric IDs. State Ojj (off) 
denotes that the UMTS NIC is shut down. In state d v 
(disconnected) the UMTS interface is active and scans for 
networks to connect to. A network is found after an average 
time 1/ceu, and the NIC enters state sjj (setup) where it tries to 
connect to the newly found access point. A connection attempt 
has an average duration of l/flu, after which it succeeds 
with probability pjj and fails with probability (1 — pu). 
After a successful connection, the UMTS NIC enters state 
cjj (connected); in this state data packets can be received and 
transmitted. The average duration of a connection is 1/7(7. 
When the connection is lost, the UMTS interface enters state 
fu (faded). In this state no datagrams can be received or 
delivered, but the MN is not yet aware of such failure and 
continues to send data until it detects, eventually, that the 
connection is not available and enters state djj- 

The oracle is modeled by the chain in Fig. |3(c)| State 
Ojj is entered when the EV_NO_WIFI event is fired (see 
Algorithm [TJ; in this state only the UMTS NIC is active. 
State Ojjw is entered when the EV_SHORT_WIFI event 
is fired; here both UMTS and WiFi are active. Finally, state 
Ow corresponds to event EV_LONG_WIFI where only the 
WiFi NIC is active. In order to reduce the number of model 
parameters, we omitted direct transitions connecting Ow and 

Ojj. 

We can see that some of the transitions on Fig.[3]are labeled 
with actions within square brackets. Actions are used to force 
two chains to make transitions simultaneously, at a rate equal 
to the product of the rates of synchronized transitions (when 
the rate is omitted, it is assumed to be 1). We use synchronized 
transitions to model the fact that the behavior of the oracle may 
affect the behavior of the UMTS or WiFi chain. Actions U 1 
and U0 are used to switch on and off the UMTS interface. 
Action Ul is executed when the transition Ow — > Ojjw is 
traversed, forcing the transition Ojj — > djj on the UMTS chain. 
On the other hand, action U0 is executed when the oracle 
traverses the transition Ojjw ~> Ow, forcing the UMTS chain 
to move to state Ojj (off) from whichever state it was in. 
Actions Wl and WO have the same effect on the WiFi NIC. 

The oracle has also another effect on the WiFi model, 
which is not shown in the figure to reduce visual clutter. The 
value of -fw, which controls the average duration of WiFi 
connections, depends on the state of the oracle chain. Recall 
that state Ow is entered when the event EV_LONG_WIFI is 
fired; therefore, in state Ow the WiFi connection should last 
longer. On the other hand, state Ojjw is entered when the 
event EV_SHORT_WIFI is fired, and in this case the WiFi 
connection should have shorter duration. Let T w and T w be 
the mean duration of long and short WiFi connections. The 
transition rate jw from cw to fw is defined as follows: if 
the oracle is in state Ow, then jw = lw = V^W' otherwise 
lw = lw ~ ^/Tw- With these rules the mean sojourn time 



in state cw is either or T w . 

The complete model of ABPS with oracle is built by 
composing the three individual chains shown in Fig. [3] The 
state space is the set of triples (.S'wiFi, Sumts, Soads), 
where SWrs € {0(7, djj, s U} cjj, fu}, S'wiFi € 
{Ow, dw, sw, cw, fw} and S omc \ e € {Ojj ,Ojjw ,Ow}- 
Not all configurations are possible (e.g., when 5 olac i e = Ow 
we know that UMTS must be in state off, hence Sumts = 0(y), 
therefore the state space is actually smaller. The model has 
been implemented using the PRISM model checker [9] and 
can be found in the Appendix. 

V. Analysis 

We use the Markov model to study how the oracle affects 
three quantities (availability, power consumption and through- 
put) with respect to the plain version of ABPS, where no oracle 
is used. Plain ABPS is modeled by removing "off" states and 
all transitions entering or exiting from them; basically, plain 
ABPS is modeled by simply removing all gray elements from 
the models from Fig. [3] 

Model Parameters: We consider the following parameter 
values, which have been empirically determined: 
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Transition rates are defined as the inverse of experi- 
mentally measured values. We set the duration of short 
WiFi connections (those for which the oracle triggers the 
EV_SHORT_WIFI event) in the range [5,40] seconds; long 
WiFi connections are set in the range [40, 120] seconds. We 
keep the values of other parameters fixed, since the time 
needed to set up a connection, or detect that a connection has 
failed, are likely to be unaffected by the duration of WiFi con- 
nections. Transition rates for the oracle have been set so that 
the expected residence times in states Ow and Ojjw matches 
the long and short WiFi connection duration, respectively. 
Recall that the mean residence time in a given state can be 
computed as the inverse of the sum of rations of all outgoing 
transitions [8 1. Therefore, the mean residence time in state Ow 
is l/Xw.uw = VTw = ^W' an< ^ ^ e mean residence time 
in state O uw is l/{\uw.w + Xuw,u) = ^Hw = T w- ^ 
mean residence time in state Ojj, where no WiFi connection is 
available, has been empirically determined as I/Xjjuw = 30 
seconds. 

Connection Availability: The connection availability is 
the long term fraction of actually available service. Formally, 
the availability is the steady-state probability that either the 
UMTS or WiFi NICs are connected (i.e., in state cjj or cw, 
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(b) Power Consumption 
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Fig. 4. Model evaluation results for plain ABPS (top) and ABPS+oracle (bottom) 



respectively). Fig. |4(a)| shows the availability computed by 

(higher is better), 



PRISM as a function of T, 



and T+. 



TABLE I 

Rewards for energy consumption estimation 



for both plain ABPS and ABPS enhanced with the oracle. 
Plain ABPS provides higher availability, especially when the 
duration of WiFi connection is short. This can be explained 
by observing that WiFi is more unreliable than UMTS (the 
average duration of a WiFi connection is much lower than 
UMTS), hence the oracle incurs the UMTS connection setup 
overhead each time the system moves from state Ow to Ojjw- 
Plain ABPS does not incur this overhead, since both interfaces 
are always active at the same time, and the setup on one 
interface may be overlapped with the other one being already 
connected. The availability improves if the value of (the 
duration of short WiFi connections) is increased. The reason 
is that longer values of give the interface being activated 
in state Ouw enough time to connect before the system shuts 
down the other one. In practice, this result suggests that the 
oracle should not trigger a EV_SHORT_WIFI when the WiFi 
connection is going to be available for a very short time only. 

Power Consumption: In order to estimate the power 
consumption, we define a reward structure in which each state 
is assigned a reward equal to the power consumption (in Watts) 
of the NICs in that state. When both NICs are connected, 
we assume that only the fastest one (WiFi) is used for data 
transmission. Therefore, in this case we assume that the 
idle interface consumes 20% of its peak power. Additionally, 
for ABPS+oracle we increased the reward of all states by 
O.iW, to account for the need to keep the GPS connection 
active, and for executing the oracle application in background. 
The contribution of other components of the MN is assumed 
to be more or less the same in both scenarios (plain ABPS 
and ABPS+oracle), so it is omitted in this analysis. Rewards 
are shown in Table [I] and are based on data from fT0| . 

Results are shown in Fig. 4(b) we observe that the ora- 
cle significantly reduces the energy requirement of the MN, 
despite the fact that it uses the GPS device to get the 
current position. We also observe that availability and power 
consumption are correlated, as expected: higher availability 
requires more energy 

Throughput: We finally evaluate the throughput provided 
by the two communication mechanisms. Again, we use a 
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reward structure in which we associate to each state the 
average throughput provided by the NIC in that state. This 
means that for the UMTS chain we associate a throughput of 
0.2 Mbps to state cjj, and for the WiFi chain we associate 
a throughput of 26 Mbps to state Cw- When both interfaces 
are connected at the same time, we only use WiFi for actual 



data transmission. As can be seen in Fig. 4(c) the oracle 
guarantees a throughput that is only marginally lower than 
that provided by plain ABPS. Unsurprisingly, the duration of 
WiFi connections plays a major role on the system throughput. 
When WiFi connections last longer, the MN can make better 
use of that to achieve higher transmission rates. This happens 
for both plain ABPS and ABPS enhanced with the oracle. 

VI. Conclusion 

In this paper we proposed an extension of the ABPS 
communication mechanism based on a software component 
(the oracle) which can predict the availability of access points 
as the MN moves. This information can be exploited to switch 
off the interface for which no access points are going to be 
available in the near future, in order to save energy. We de- 
scribed an actual prototype implementation of the oracle based 
on the WiGLE service; in order to better evaluate the impact of 
the oracle on ABPS, we defined a performance model based 
on continuous-time Markov chains that is quite simple and 
can be efficiently solved. We used the model to compare the 
connection availability, steady-state power consumption and 
throughput of plain ABPS and ABPS with oracle, for different 
scenarios. The results show that the oracle can provide a 
significant reduction of the power consumption with marginal 
reduction of availability and throughput. The Markov model 
is currently being used to drive the full implementation of the 



oracle-based ABPS, by providing quick performance estimates 
of various implementation alternatives. 

Appendix 

PRISM MODELS 

A. Plain ABPS Model 

// abps-plain . sm 
ctmc 

/ / Externally defined parameters 
const double T_W_plus; 
const double T_W_minus ; 

// UMTS model transition rates 
const double alpha_U - 1/6.024; 
const double beta_U = 1/1.5; 
const double gamma_U = 1/ 600 ; 
const double mu_U = 1.0; 
const double p_U = . 99; 

/ / WiFi model transition rates 

const double alpha_W = 1/7.5; 

const double beta_W = 1/1.5; 

const double gamma_W_plus = 1 /T_W_plus ; 

const double gamma_W_minus = l/T_W_minus ; 

const double mu_W = 1.0; 

const double p_W = 0.9; 

// Oracle transition rates 

const double lambda_12 = 30 ; // gamma_U; 

const double lambda_21 = . 5*gamma_W_minus ; 

const double lambda_2 3 = lambda_21; 

const double lambda_32 = gamma_W_plus ; 

/ / Power consumption for UMTS 

const double e_U_0 = 0.0; 

const double e_U_l - 0.12 

const double e_U_2 - 0.31 

const double e_U_3 = 0.62 

const double e_U_4 - 0.25; 

/ / Power consumption for WiFi 

const double e_W_0 = 0.0; 

const double e_W_l - 0.08; 

const double e_W_2 = 0.19; 

const double e_W_3 = 0.38; 

const double e_W_4 = 0.15; 

// NIC throughput (Mbps) 
const double Tput_U - 0.2; // UMTS 
const double Tput_W - 26; // WiFi 



[] s_W=l -> alpha_W: (s_W'=2) ; 

[] s_W=2 -> beta_W*p_U: (s_W'=3) + 

beta_W* (1.0-p_W) : (s_W'=l) ; 

[] s_W=3 -> (s_oracle - 3 ? 

g a mma_W_p 1 u s : 
gamma_W_minus ) : (s_W'=4) ; 

[] s_W=4 -> mu_W: (s_W'=l) ; 
endmodule 

// 

// Oracle model definition 
// 

module oracle 

// 1 - UMTS only 
// 2 - UMTS + WiFi 
// 3 - WiFi only 
s_oracle : [1..3] init 2; 



lambda_12 
lambda_2 1 
lambda_2 3 
lambda_32 



(s_oracle' =2) 
(s_oracle' = 1) 
(s_oracle' =3) 
(s_oracle' =2) 



[] s_oracle=l 
[] s_oracle=2 
[] s_oracle=2 
[] s_oracle=3 
endmodule 

// 

// reward structures 
// 



formula U_connected = s_U=3; // is UMTS connected? 
formula U_not_connected = s_U!=3; // is UMTS NOT connected 
formula W_connected = s_W=3 ; // is WiFi connected? 
formula W_not_connected = s_W ! =3 ; // is WiFi NOT connected 

/ / Power Consumption 
rewards " energy" 
true: e_base 



// add baseline power consumption 
// to all states 



s_U=0 


e_U_0 


s_u=l 


e_u_l 


S_U=2 


e_u_2 


s_U=3 


e_u_3 


s_U=4 


e_u_4 


s_w=0 


e_w_0 


S_W=1 


e_w_l 


S_W=2 


e_w_2 


S_W=3 


e_w_3 


S_W=4 


e_W_4 



endrewards 

// Throughput 

rewards "throughput" 

W_connected & U_not_connected 

unconnected & W_not_connected 

U_connected & W_connected 

endrewards 



Tput_W; 
Tput_U; 
Tput_W; 



// Baseline power consumption 
const double e_base = 0.0; 

// 

// UMTS interface definition 
// 

module umts 

// state enumeration: 

// 1 = disconnected 

112= setup 

// 3 = connected 

// 4 = failed 

s_U : [ 1 . . 4 ] init 1 ; 



_U=1 -> alpha_U: (s_U' =2) ; 
_U=2 -> beta_U*p_U: (s_U' =3) + 

beta_u* (1 . 0-p_U) : (s_u' =1) ; 
_U=3 -> gamma_U: (s_U' =4) ; 
_U=4 -> mu_U: (s_U'=l) ; 



endmodule 
// 

// WiFi interface definition 
// 

module wifi 

s_W : [ 1 . . 4 ] init 1 ; 



B. Plain ABPS Property Specification 

// abps-plain . csl 

// Stationary energy consumption rate 
"power": R{ "energy" } =? [S] 

// Stationary connection availability 
"availability": S=? [ s_U = 3 I s_W = 3 ] 

// Stationary throughput 
"throughput": R{ "throughput "} =? [S] 

C. ABPS+Oracle Model 

// abps-oracle . sm 
ctmc 

// Externally defined parameters 
const double T_W_plus; 
const double T_W_minus ; 

// UMTS model transition rates 
const double alpha_U - 1/6.024; 
const double beta_U = 1/1.5; 
const double gamma_U = 1/600; 



const double mu_u = 1.0; 

const double p_U - 0.99; 

// WiFi model transition rates 

const double alpha_w - 1/7.5; 

const double beta_w = 1/1.5; 

const double gamma_W_plus - 1/T_w_plus; 

const double gamma_W_minus = l/T_W_minus; 

const double mu_W = 1.0; 

const double p_W - 0.9; 

// Oracle transition rates 

const double lambda_12 = 30; 

const double lambda_21 = . 5*gamma_W_minus; 

const double lambda_23 = lambda_21; 

const double lambda_32 = gamma_W_plus ; 



module oracle 

// State space enumeration: 
/ / 1 = UMTS only 
112 = UMTS + WiFi 
// 3 = WiFi only 
s_oracle : [1..3] init 2; 

[wifi_l] s_oracle=l -> lambda_12 

[wifi_0] s_oracle=2 -> lambda_21 

[umts_0] s_oracle=2 -> lambda_23 

[umts_l] s_oracle=3 -> lambda_32 
endmodule 

// 

// Definition of reward structures 
// 



(s_oracle' =2 ) 
(s_oracle' =1) 
(s_oracle' =3) 
( s_oracle' =2 ) 



// Power consumption for UMTS 

const double e_U_0 - 0.0; 

const double e_u_l = 0.12; 

const double e_U_2 = 0.31; 

const double e_U_3 - 0.62; 

const double e_U_4 = 0.25; 

// Power consumption for WiFi 
const double e_W_0 = 0.0; 
const double e_w_l =0.08 
const double e_w_2 = 0.19 
const double e_w_3 = 0.38 
const double e_W_4 = 0.15 

// NIC throughput (Mbps) 

const double Tput_U = 0.2; // UMTS 

const double Tput_w =2 6; // WiFi 

// 

// UMTS model definition 

// 

module umts 

// state enumeration: 

// = off 

// 1 = disconnected 

112= setup 

// 3 = connected 

114 = failed 

s_U : [0 . . 4 ] init 1; 



formula U_connected = s_U=3; // is UMTS connected? 
formula U_not_connected = s_U!=3; // is UMTS NOT connected? 
formula W_connected = s_W=3; // is WiFi connected? 
formula W_not_connected = s_W!=3; // is WiFi NOT connected? 

// Power Consumption 
rewards "energy" 

true: 0.1; // add baseline power consumption 
// to all states to account for 
// GPS usage and CPU cycles 
e_u_0 ; 



s_U=0 
s_U=l 
S_U=2 
S_U=3 
S_U=4 

s_W=0 
S_W=1 
S_W=2 
S_W=3 
S_W=4 
endrewards 



e_U_l 
e_U_2 
e_u_3 
e_u_4 

e_w_0 
e_w_l 
e_w_2 
e_w_3 
e_w_4 



// Throughput 

rewards "throughput" 

W_connected & U_not_connected 
U_connected & W_not_connected 
U_connected & W_connected 

endrewards 



Tput_W 
Tput_U 
Tput_W 



] s_U=l -> alpha_U: (S_U'=2) ; 

] s_U=2 -> beta_u*p_U: (s_U' =3) + 

beta_u* (1 . 0-p_U) : (s_U' =1) ; 
] s_U=3 -> gamma_U: (s_U'=4) ; 
] s_U=4 -> mu_U: (s_U'=l) ; 

umts_0] true -> (s_U'=0); 



[umts_l] s_U=0 -> (S_U'=1); 

endmodule 

// 

// WiFi model definition 

// 

module wifi 

s_W : [0 . . 4 ] init 1; 

[] s_W=l -> alpha_W: (s_W =2) ; 

[] s_w=2 -> beta_w*p_U: (s_W =3) + 

beta_w* (1 . 0-p_W) : (s_W =1) ; 

// If the oracle is in state 3, the mean 

// duration of WiFi connected state is 

// set to T_W_plus 

[] s_W=3 -> ( s_oracle =3 ? 

gamma_W_plus : 
gamma_W_minus ) : (s_W'=4) ; 

[] s_W=4 -> mu_W: (s_W'=l) ; 

[wifi_0] true -> (s_W'=0); 

[wifi_l] s_W=0 -> (s_W'=l); 

endmodule 

// 

// Oracle model definition 
// 



D. ABPS+Oracle Property Specification 

II abps-oracle . csl 

// Stationary energy consumption rate 
"power": R{ "energy" } =? [S] 

// Stationary connection availability 
"availability": S=? [ s_U = 3 | s_W = 3 ] 

// Stationary throughput 
"throughput": R{ "throughput "} =? [S] 
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